home *** CD-ROM | disk | FTP | other *** search
/ The X-Philes (2nd Revision) / The X-Philes Number 1 (1995).iso / xphiles / hp48hor1 / fpgdir.doc < prev    next >
Text File  |  1995-03-31  |  10KB  |  232 lines
  1. A Dangerous Discovery and HP's Swift Response 
  2. by Joe Horn & Bill Wickes. 
  3.  
  4. úÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ 
  5. 3 A Cautionary Tale for HP 48 Programmers 3 
  6. àÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄù 
  7.  
  8. (Comp.sys.handhelds) 
  9. Item: 3374 by _joehorn at hpcvbbs.UUCP 
  10. Author: [Joseph K Horn] 
  11.   Subj: HP 48 Faster PGDIR 
  12.   Date: Wed Jun 05 1991 
  13.  
  14. FPGDIR, a FAST PGDIR, by Joseph K Horn.  Makes PGDIR obsolete. 
  15. úÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ 
  16. 3[NO, NO, NO IT DOESN'T!  20/20 Hindsight.  Read On...  -jkh-]3 
  17. àÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄù 
  18. When you use PGDIR on a very large directory, it can take a long time to 
  19. finish.  For example, I just used Donnelly's XTIME function to time PGDIR on a 
  20. big directory, and it took a painful 50 seconds! 
  21.  
  22. Bill Wickes explains why in his excellent book, "HP 48 Insights": 
  23.  
  24.      "PGDIR removes a directory specified by name.  It does 
  25.       this by recursively executing CLVAR and PURGE recursively 
  26.       on each subdirectory until the original directory is 
  27.       empty.  (This process can take a relatively long time if 
  28.       the directory is large.)"  [Part I, page 96] 
  29.  
  30. Guess what!  There's a better way!  [No there isn't!  Read on... -jkh-] 
  31.  
  32. Those of you with HP-41CX's will remember the CLRALMS command that cleared all 
  33. the alarms out.  If you had a lot of alarms, it took a long time to finish, 
  34. because it looped through the alarm buffer clearing each one individually.  But 
  35. a much better way was to treat the entire buffer as one object, and clear it in 
  36. one fell swoop.  This was possible with the buffer clearing functions available 
  37. in several plug-in ROMs.  For example, with the Extended-IL ROM, just execute 
  38. 10 CLRBUF, and instantly the entire alarm buffer gets cleared, no matter how 
  39. large it is. 
  40.  
  41. It turns out that there is a similar trick for purging directories on the HP 
  42. 48.  Rather than painfully looping through them, clearing their contents, we 
  43. can treat the whole thing as a single object and PURGE it in one fell swoop. 
  44.  
  45. Here's the trick.  The HP 48 Owner's Manual says: 
  46.  
  47.      "Once a directory is empty, you can purge it like any 
  48.       other variable -- put its name on the stack and execute 
  49.       PURGE."  [Volume 1, page 123] 
  50.  
  51. But "empty" means "when VARS == { }".  And VARS == { } when all the vars are 
  52. "hidden" behind a null-named object (see NULLNAME.DOC on Goodies Disk #1). 
  53.  
  54. So the quick way to purge a directory is: 
  55. úÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ 
  56. 3[DO NOT DO THE FOLLOWING!  IT'S TOO DANGEROUS!  Read on...  -jkh-]3 
  57. àÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄù 
  58. (1) Put its name on the stack; 
  59. (2) Get into that directory: DUP EVAL; 
  60. (3) Unhide everything (just in case): '' PURGE; 
  61. (4) Hide all its vars: 0 '' STO; 
  62. (5) Go back to the parent directory: UPDIR; 
  63. (6) Purge the "empty" directory: PURGE. 
  64.  
  65. This process is automated by the following replacement for PGDIR: 
  66. úÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ 
  67. 3[DO NOT USE THIS PROGRAM!  Read on...  -jkh-]3 
  68. àÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄù 
  69. ---------------------< FPGDIR >--------------------------------- 
  70. %%HP:T(1); 
  71. \<< 
  72.     IF DUP TYPE 6 == 
  73.     THEN 
  74.       IF DUP VTYPE -1 == 
  75.       THEN DROP 
  76.       ELSE 
  77.         IF DUP VTYPE 15 == 
  78.         THEN DUP EVAL 0 # 15777h SYSEVAL DUP PURGE STO UPDIR PURGE 
  79.         ELSE 515 DOERR 
  80.         END 
  81.       END 
  82.     ELSE 514 DOERR 
  83.     END 
  84. \>> 
  85. ---------------------------------------------------------------- 
  86.  
  87. Except for its improved speed, its action is exactly like PGDIR.  It even 
  88. generates the same error messages as PGDIR in case of bad arguments. 
  89. Nonexistent names simply get dropped (like PGDIR does). 
  90.  
  91. To use: place name of directory on stack, and run it. 
  92.  
  93. It does full argument type checking, so it should be idiot proof. 
  94. úÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ 
  95. 3[Unless the idiot is the author!  Read on...  -jkh]3 
  96. àÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄù 
  97. I keep it assigned to my blue-shifted DEL key.  That way it takes only three 
  98. keystrokes to delete a directory (tic, menu, FPGDIR). 
  99.  
  100. It should be in "system RPL" ...  but that's left as an exercise for the 
  101. reader.  :-) 
  102.  
  103. --  Joseph K Horn  --  Peripheral Vision, Ltd.  -- 
  104.  
  105. ---------- 
  106.   Resp: 1 of 4 by billw at hpcvra.cv.hp.com. 
  107. Author: [William C Wickes] 
  108.   Date: Thu Jun 06 1991 
  109.  
  110. An extra benefit of Joseph's method is that it can not only blow away a 
  111. directory instantly, but it can also blow away everything in main RAM at no 
  112. extra charge. 
  113.  
  114. > Except for its improved speed, its action is exactly like PGDIR. 
  115.  
  116. Not quite.  PGDIR is safe. 
  117.  
  118. In my excellent book I explained what PGDIR does, not WHY it does it.  Guess 
  119. what!  There isn't a better way!  What?  you mean there's a reason that PGDIR 
  120. goes through all that agony?  Well, yes: directories are not composite 
  121. objects, and thus a directory in temporary memory, such as might be created by 
  122. PURGE, must not contain referenced objects.  Garbage collection is doomed by 
  123. such references, so PGDIR's labor is to remove the directory without leaving 
  124. any references to any of its innards.  PURGE doesn't bother with such 
  125. niceties, so it's not allowed to handle directories.  Fooling it with 
  126. null-named variables is courting disaster.  FPGDIR may work safely most of the 
  127. time if you execute a system halt (ON-C) first, but even that's not 100% 
  128. bulletproof. 
  129.  
  130. In case the above is too subtle for anyone, just take it that using FPGDIR 
  131. (i.e.  creating a null-named variable, then purging a directory) is NOT a good 
  132. thing to do. 
  133.  
  134. Bill Wickes 
  135. HP Corvallis 
  136.  
  137. ---------- 
  138.   Resp: 2 of 4 by _joehorn at hpcvbbs.UUCP 
  139. Author: [Joseph K Horn] 
  140.   Date: Thu Jun 06 1991 
  141.  
  142. Bill Wickes writes that Joe Horn's FPGDIR is too dangerous to use. 
  143.  
  144. Please post an example of how to lose memory with its use.  I've tried, 
  145. and haven't been able to.  Thanx! 
  146.  
  147. -- Joe Horn -- 
  148.  
  149. ---------- 
  150.   Resp: 3 of 4 by billw at hpcvra.cv.hp.com. 
  151. Author: [William C Wickes] 
  152.   Date: Fri Jun 07 1991 
  153.  
  154. Joe Horn requests: 
  155.  
  156. > Please post an example of how to lose memory with its use.  I've tried, 
  157. > and haven't been able to. 
  158.  
  159. Using FPGDIR gives the 48 a chance to execute code at a random address; what 
  160. will actually happen is hard to predict--most of the time you just get a 
  161. system halt, but you can get Memory Clear (it's just like executing SYSEVAL 
  162. with random addresses).  The easiest way to see the danger is to recall some 
  163. objects from a directory you are going to purge, then execute FPGDIR.  
  164. Everything looks fine, but now execute MEM and see your recalled objects turn 
  165. to Externals.  Try executing one, if you're brave.  In a running program, of 
  166. course, this can be disastrous--one example is to insert a MEM into FPGDIR 
  167. after the directory PURGE, then use FPGDIR to purge the subdirectory that 
  168. contains FPGDIR.  I tried this on my HP48 (with everything archived, of 
  169. course), and got a system halt.  Another way is to use FPGDIR to purge a 
  170. directory containing a suspended program, then execute MEM and CONT.  (The use 
  171. of MEM in these examples forces a garbage collection, which otherwise might 
  172. happen most anytime, like a ticking time bomb.) 
  173.  
  174. > Thanx! 
  175.  
  176. Yer welcome! 
  177.  
  178. Bill Wickes 
  179. HP Corvallis 
  180.  
  181. ---------- 
  182.   Resp: 4 of 4 by _joehorn at hpvvbbs.UUCP 
  183. Author: [Joseph K Horn] 
  184.   Date: Sat Jun 08 1991 
  185.  
  186. Bill Wickes writes that running my FPGDIR after recalling objects from the 
  187. target directory to the stack can cause problems. 
  188.  
  189. Wow!  That's for sure!  I just tried it, and the very first attempt tanked 
  190. everything in the machine. 
  191.  
  192. Rats.  The moral here is twofold: 
  193.  
  194. (1) The obvious: don't use FPGDIR unless you KNOW FOR SURE that there are no 
  195. references to objects that will be left floating in limbo. 
  196.  
  197. (2) Less obvious: Be Careful When You Hide Objects In Directories!  Many 
  198. articles and programs about "hiding" things have floated down this bitstream, 
  199. and not once did anybody mention that hiding things in directories can send 
  200. the 48 out to lunch.  But if ALL the items in a directory are hidden, it's an 
  201. accident waiting to happen.  Because then simply PURGEing the directory (if 
  202. there are any memory references to its contents) will cause problems at the 
  203. next garbage collection. 
  204.  
  205. The first moral is worded with "unless" because the situation is exactly the 
  206. same for the new 256K and 512K bankswitched cards now available for the 48.  I 
  207. just played with a 512K card tonight at the 48 Club meeting in L.A., and it 
  208. has a BANKN function that allows you to bank switch WITHOUT PERFORMING A 
  209. SYSTEM HALT.  The owner's manual clearly states that doing this while there 
  210. are any memory references to objects in the bank being switched out will "at 
  211. best cause unpredictable results." The reason this is so is the same as the 
  212. reason that FPGDIR is dangerous.  If Tripod can sell an item with 
  213. functionality that's dangerous to use and assumes that the user takes proper 
  214. precautions, then I hope I can give away FPGDIR for free with the same danger 
  215. and assumptions. 
  216.  
  217. What scares me, however, is the second moral.  People are hiding things 
  218. gleefully, without any idea that Memory Clear awaits them if they don't know 
  219. the pitfalls of PURGE on directories whose contents are all hidden. 
  220.  
  221. EduCALC Goodies Disk #5 will, of course, have all this documented, hopefully 
  222. to make up for the blissful endorsement of using null-named objects that has 
  223. been on previous Goodies Disks.  [You're reading it!  -jkh-] 
  224.  
  225. Thanx, Bill, for warning us of the dangers here, before my "wonderful new 
  226. discovery" (*sigh*) proliferated too far. 
  227.  
  228. -- a crestfallen jkh -- 
  229. úÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ 
  230. 3[If nothing else, this should teach the reader the value of participating3 
  231. 3in the activity on the Hewlett Packard Bulletin Board System!  -jkh-]    3 
  232. àÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄù